电子签名 内容 概述 数字证书 身份认证 密钥相关 第三方CA 其他场景 法规参考 概述 参考：ADempiere的电子签名 http://wiki.adempiere.net/Sponsored_Development:_Document_Signing 这是我看到的最好的文章之一：数字证书原理 http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html itext实现pdf签名 http://blog.csdn.net/liumengya007007/article/details/53129323 使用USBkey进行身份认证 http://blog.csdn.net/qq_26265699/article/details/51143592 数字证书 数字证书（CA证书）是指可证实电子签名人与电子签名制作数据有唯一关联的数据信息或者其他电子记录，相当于现实社会中的《居民身份证》。在实际使用环境中，数字证书的载体往往是一个特殊的USB优盘，是一种具有运算功能的硬件存储介质——USB-KEY。USB-KEY中内置了智能芯片，并有专用安全区来保存电子签名制作数据。 数字证书由电子签名认证服务提供者，习惯上称作CA中心、CA认证中心等，为数字证书申请者提供证书发放、证书管理、证书注销等服务。常见的数字证书类型主要有：个人数字证书、单位数字证书、单位员工数字证书、服务器证书、VPN证书、WAP证书、代码签名证书和表单签名证书。 身份认证 身份认证通常使用公开密钥体系（PKI）和数字证书结合完成，数字证书采用公钥（双钥）加密体制，即利用一对互相匹配的密钥进行“加密”和“签名”。比如RSA算法： 加密体制包含3个算法：KeyGen（密钥生成算法），Encrypt（加密算法）以及Decrypt（解密算法）。 签名体制也包含3个算法：KeyGen（密钥生成算法），Sign（签名算法），Verify（验证算法）。 简单的说：加密使用对方的公钥，签名使用自己的私钥。如下图：  发送一份保密文件时，发送方使用**对方公钥**对数据加密，而接收方使用**自己私钥**解密。 发送多份签名文件时，发送方使用**自己私钥**对数据签名，而接收方使用**对方公钥**验证。 公钥密码体制的核心思想是：加密和解密采用不同的密钥。这是公钥密码体制和传统的对称密码体制最大的区别。对于传统对称密码而言，密文的安全性完全依赖于密钥的保密性，一旦密钥泄漏，将毫无保密性可言。但是公钥密码体制彻底改变了这一状况。在公钥密码体制中，公钥是公开的，只有私钥是需要保密的。 数字证书颁发过程一般为：用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息(称作P10请求)传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和其公钥信息，同时还附有认证中心的签名信息。  在确认私钥拥有者（强口令或生物特征识别）并使用可信的时钟服务后，以甲方向乙方发送一个合同的“理想”认证为例。 甲的整个发送过程如下 : 1. 创建对称密钥 ( 相应软件生成，并且是一次性的 ) ，用其加密合同，并用乙的公钥打包对称密钥。 2. 创建数字签名，对合同进行散列算法 ( 如 MD5 算法 ) 并产生原始摘要，甲用自己的私钥加密该摘要 ( 公 / 私钥既可自己创建也可由CA 提供 ) 。 3. 最后 , 甲将加密后的合同、打包后的密钥、加密后的摘要 , 以及甲的数字证书 ( 由权威机构 CA 签发 ) 一起发给乙。 而乙接收加密文件后，需要完成以下动作 : 1. 接收后，用乙的私钥解密得到对称密钥 , 并用对称密钥解开加密的合同 , 得到合同明文。 2. 通过甲的数字证书获得属于甲的公钥 , 并用其解开摘要 ( 称做摘要 1) 。 3. 对解密后的合同使用和发送者同样的散列算法来创建摘要 ( 称做摘要 2) 。 4. 比较摘要 1 和摘要 2, 若相同 , 则表示信息未被篡改 , 且来自于甲。 密钥相关 1、私钥的唯一性 严格地讲，私钥既然是世上唯一且只由主体本身持有，它就必须由主体的计算机程序来生成。因为如果在别处生成将会有被拷贝的机会。然而在实际应用上并非如此，出于某些特殊需要(例如，如果只有一份私钥，单位的加密文件就会因为离职员工带走 私钥而无法解密。)加密用的公/私钥对会要求在可信的第三方储存其备份。这样，加密用的私钥可能并不唯一。然而签名用的私钥则必须保持唯一，否则就无法保证被签名信息的不可否认性。 在生成用户的密钥对时，用于加密的公/私钥对可以由CA、RA产生，也可以在用户终端的机器上用专用的程序(如浏览器程序或认证软件)来产生。用于数字签名的密钥对原则上只能由用户终端的程序自行产生，才能保证私钥信息的私密性以及通信信息的不可否认性。 有人可能会产生疑问：有的加密和签名的密钥对都是由软件运营商代替客户生成的，这是否破坏了上述的私钥唯一性原则呢？答案是否定的。这时候，私钥的唯一性要依靠法律合同的保证以及操作过程中相应制度的约束，使得不可否认性得到支持。出于这种机制，我们仍然可以认为，用户的签名私钥是唯一的。 2、私钥的保护 数字证书可以在网上公开，并不怕别人盗用和篡改。因为证书的盗用者在没有掌握相应的私钥的情况下，盗用别人的证书既不能完成加密通信，又不能实现数字签名，没有任何实际用处。而且，由于有CA对证书内容进行了数字签名，在网上公开的证书也不怕黑客篡改。我们说，更该得到保护的是储存在介质中的私钥。如果黑客同时盗走了证书和私钥，保密就失败了。 3、文件格式 PKCS 全称是 Public-Key Cryptography Standards ，是由 RSA 实验室与其它安全系统开发商为促进公钥密码的发展而制订的一系列标准，PKCS 目前共发布过 15 个标准。 常用的有： PKCS#7 ：Cryptographic Message Syntax Standard 常用的后缀是： .P7B .P7C .SPC PKCS#10 ：Certification Request Standard 常用的后缀是： .P10 .CRS PKCS#12 ：Personal Information Exchange Syntax Standard 常用的后缀有： .P12 .PFX X.509是常见通用的证书格式。所有的证书都符合为Public Key Infrastructure (PKI) 制定的 ITU-T X509 国际标准。 X.509 DER 编码(ASCII)的后缀是： .DER .CER .CRT X.509 PAM 编码(Base64)的后缀是： .PEM .CER .CRT 密钥库文件格式【Keystore】 格式 后缀 描述 特点 JKS .jks .ks 【Java Keystore】 密钥库的Java实现版本，provider为SUN 密钥库和私钥用不同的密码进行保护 JCEKS .jce 【JCE Keystore】 密钥库的JCE实现版本，provider为SUN JCE 1、相对于JKS安全级别更高 2、保护Keystore私钥时采用TripleDES PKCS12 .p12 .pfx 【PKCS #12】 个人信息交换语法标准 1、包含私钥、公钥及其证书 2、密钥库和私钥用相同密码进行保护 BKS .bks 【Bouncycastle Keystore】 密钥库的BC实现版本，provider为BC 基于JCE实现 UBER .ubr 【Bouncycastle UBER Keystore】 密钥库的BC更安全实现版本，provider为BC 证书文件格式【Certificate】 格式 后缀 描述 特点 DER .cer .crt .rsa 【ASN .1 DER】用于存放证书 不含私钥、二进制 PKCS7 .p7b .p7r 【PKCS #7】加密信息语法标准 1、p7b以树状展示证书链，不含私钥 2、p7r为CA对证书请求签名的回复，只能用于导入 CMS .p7c .p7m .p7s 【PKCS #7】加密信息语法标准 1、p7c只保存证书 2、p7m：signature with enveloped data 3、p7s：时间戳签名文件 PEM .pem 【Printable Encoded Message】 1、该编码格式在RFC1421中定义 2、ASCII文件，一般基于base 64编码 3、可以放证书或者私钥，或者两者都有 4、如果只含私钥的话，一般用.key扩展名，而且可以有密码保护 PKCS10 .p10 .csr 【PKCS #10】证书请求标准 1、证书签名请求文件 2、ASCII文件 3、CA签名后以p7r文件回复 SPC .pvk .spc 【Software Publishing Certificate】 微软公司特有的双证书文件格式， 经常用于代码签名，其中 1、pvk用于保存私钥 2、spc用于保存公钥 第三方CA 如果对公众发布信息，企业自建的CA中心肯定没有公信力，可使用第三方CA认证企业的证书。 全球CA认证服务有三大巨头：Verisign、Thawte、GeoTrust。我国CA的发展比较晚，2005年4月1日才颁布“中华人民共和国电子签名法”。工信部作为指定的电子认证主管部门，同年颁布了《电子认证服务管理办法》。截止到2014年10月，获得电子认证服务行政许可的认证机构名单共有36家，数据如[链接](http://xxgk.miit.gov.cn/gdnps/content.jsp?id=4136207)： 上述CA大体分两类：非区域性和区域性。 非区域性CA： - 金融CFCA安全认证中心：中国人民银行联合12家银行建立 - 中国电信认证中心（CTCA） - 海关认证中心（SCCA） - 国富安CA安全认证中心：国家外贸部EDI中心建立 区域性CA： - 广东CA：广东电子商务认证中心的“网证通”。 - 上海CA：SHECA的UCA（全国协卡认证体系）。 - 各省市的CA机构 CA通用 其他场景 电子缔约是最新的网商应用。比如美国的DocuSign，国内的上上签。 某大型电商平台就发生了一件关于电子协议的纠纷：一天，一个商户发现，目前网站的协议和自己当初看到的协议不一样。于是商户把网站告上法庭。但是由于所有的协议都是由网站制定，且保存在网站，所以双方都无法证明现在的电子证据有无被修改过。最终，网站输掉了这场官司。 国内的互联网企业的缔约方式主要有三种，最常用的就是，所有签约与确认在自身系统完成，其既是合同当事人一方，又是拥有合同并有修改能力的唯一一方，因而无法自证清白。还有一种就是，线上下单再派专人线下签约。但是，这常常使得线上行为与线下行为脱节难以关联，签约效率低下，成本高昂，无法满足企业快速扩展的需求。再就是一些特定行业，针对少量客户采用U盾签约的方式。但身份验证程序复杂、耗时长，用户签约成本高，体验不好。 上上签的做法是，基于云的电子缔约方式，用户不需要使用任何的Ukey或者专用软件，只需要在上上签云平台上就可以完成整个协议的签署。所有的协议进入云系统以后，不管是甲方还是乙方，均无法对合同进行修改；所有的用户数据包括合同均采用全世界通用的商业及政府数据加密标准，连上上签内部员工也无法获得解密过的合同文件。每笔签约均会打上国家授时中心提供的“时间戳”服务，让用户所有的行为均可被精确追踪查询到；平台提供基于云端的解决方案，解决方案的部署在1个星期之内就可以完成，而且完全不改变企业原来的流程。 自身产品保障之外，上上签还通过合作的方式加强了公证司法效力保障。企业在上上签上可以进行身份验证，同时，提供一站式电子数据存管与公证方案。 http://finance.eastmoney.com/news/1682,20150417498000986.html 法规参考 2004年8月28日，第十届全国人大常委会第十一次会议审议通过了《中华人民共和国电子签名法》（以下简称《电子签名法》），根据《电子签名法》的规定，电子签名是指数据电文中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。与手写签名或者盖章一样，电子签名有两个基本功能：一是用于识别签名人的身份，二是表明签名人对文件内容的认可。 与电子签名密切相关的是电子签名制作数据和电子签名验证数据。电子签名制作数据，就是用于生成电子签名并将电子签名与电子签名人可靠地联系起来的字符、编码等数据。电子签名验证数据，就是用于验证电子签名的数据，包括代码、口令、算法或者公钥等。 《电子签名法》规定，可靠的电子签名与手写签名或者盖章具有同等的法律效力，可靠电子签名具备以下四个特性： （1）电子签名制作数据的专有性/唯一性； （2）电子签名制作数据的保密性； （3）电子签名的防篡改性； （4）数据信息的防篡改性。 《中华人民共和国合同法》 第十条：当事人订立合同，有书面形式、口头形式和其他形式 。 第十一条：书面形式是指合同书、信件和数据电文（包括电报、电传、传真、电子数据交换和电子邮件）等可以有形地表现所载内容的形式。 《中华人民共和国电子签名法》 第十四条：可靠的电子签名与手写签名或者盖章具有同等的法律效力。 《中华人民共和国电子签名法》 第十三条：“电子签名同时符合下列条件的，视为可靠的电子签名： 1）电子签名制作数据用于电子签名时，属于电子签名人专有； 2）签署时电子签名制作数据仅由电子签名人控制； 3）签署后对电子签名的任何改动能够被发现； 4）签署后对数据电文内容和形式的任何改动能够被发现。 当事人也可以选择使用符合其约定的可靠的条件的电子签名。
